\documentclass[11pt, a4paper]{report}

\usepackage[utf8]{inputenc}
\usepackage[spanish]{babel}
\usepackage{graphicx}
\usepackage{fancyhdr}
\usepackage{array}
\usepackage{subfig}
\usepackage[lm]{sfmath}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\renewcommand*\familydefault{\sfdefault}
\usepackage{color}

\usepackage{listings}



\definecolor{gray}{gray}{0.5}
\definecolor{green}{rgb}{0,0.5,0}

\usepackage[left=3cm,right=3cm,bottom=3cm,top=3cm]{geometry}

\AtBeginDocument{\renewcommand\bibname{Referencias}}

\newcommand{\imgdir}{imagenes}
\graphicspath{{\imgdir/}}

\def\thesection{\arabic{section}}

\title{66.09 - Laboratorio de Microcomputadoras - Trabajo pr\'actico Final}
\author{Alan Kharsansky \and David Vilaseca}

\date{\today}

\begin{document}
\include{caratula}

%Cabeceras y pies de página
\pagestyle{fancy}%\textbf{}
\lhead{}
\chead{}
\rhead{66.09 - Laboratorio de Microcomputadoras}
\lfoot{\scriptsize{Trabajo pr\'actico Final - 1er cuatrimestre 2009 \\ Alan Kharsansky (87158), David Vilaseca (87156) \\ \textbf{Fecha de entrega:} 24 de junio de 2009}}
\cfoot{}
\rfoot{\thepage}

%Inicio del informe
\tableofcontents

\chapter*{Introducci\'on}
\addcontentsline{toc}{chapter}{Introducci\'on}

\section{UAV, QuadRotor, ?`Qu\'e es eso?}
El t\'ermino  UAV (Unmanned Aerial Vehicle) se usa para referirse a un veh\'iculo a\'ereo no tripulado. Un caso particular de esto es el QuadRotor.
Un QuadRotor es un dispositivo capaz de volar gracias a 4 h\'elices que le dan el sustento necesario para despegarse del piso.

\begin{center}
\includegraphics[scale=0.3]{quadrotor-v1-3d.pdf}
\end{center}

\section{?`Por qu\'e un QuadRotor?}
Elejimos hacer un QuadRotor por su simplicidad en varios aspectos. En primer lugar desde el punto de vista de la implementaci\'on mec\'anica un QuadRotor es simple en el sentido de que las \'unicas partes m\'oviles que tiene son las h\'elices. Dado que estas est\'an acopladas directamente a los ejes de los motores no es necesario implementar ning\'un tipo de mecanismo. Esto es un punto a favor bastante grande ya que nuestro background en mec\'anica es deja bastante que desear.

Otra ventaja interesante del QuadRotor en t\'erminos de simplicidad es la cancelaci\'on de torque total que se obtiene (ya que 2 motores giran hacia un lado y 2 hacia otro). Esto nos permite dejar de lado consideraciones respecto a la estabilizaci\'on del dispositivo en el eje vertical.

Por \'ultimo pero no menos importante, tener cuatro h\'elices dispuestas en dos ejes ortogonales nos permite controlar el QuadRotor de una forma muy simple.

Para realizar el sensado de la orientaci\'on usaremos un sensor de rotaci\'on 3DOF\footnote{Degrees Of Freedom} que obtuvimos en forma de pr\'estamo.

Tambi\'en hay una motivaci\'on no-t\'ecnica para hacer este proyecto: hac\'ia mucho tiempo ten\'iamos ganas de implementar algo con estas caracter\'isticas.

\section{Principio de funcionamiento}

Para controlar el QuadRotor es necesario generar incrementos en la potencia entregada a cada motor. Se asume que la plataforma esta volando estable con una potencia de motores $PWM_Q$ (en los cuatro motores).
Hay tres posibilidades de giro de la plataforma: roll, pitch y yaw. Roll y pitch son giros en torno a los ejes horizontales del QuadRotor. Una inclinaci\'on en cualquiera de estos ejes produce un movimiento lineal cuya velocidad depende del \'angulo (esto se denomina \'angulo de ataque). Yaw es un giro respecto a la vertical y no produce movimiento lineal.
\begin{center}
\includegraphics[scale=0.6]{axes}
\end{center}

Para modificar el pitch y el roll es necesario incrementar la potencia de un motor. De esta manera la plataforma de inclina en torno al eje correspondiente. En cambio para modificar el yaw se incrementa en igual medida la potencia de dos motores del mismo eje. Esto genera un torque resultante que hace que la plataforma gire. Recordar que dos motores giran para un lado y dos para el otro.

\begin{center}

\centering
\begin{minipage}[c]{.45\linewidth}
\centering
\includegraphics[scale=0.5]{roll} 
\end{minipage}
\begin{minipage}[c]{.45\linewidth}
\centering
\includegraphics[scale=0.5]{pitch} 
\end{minipage}

\end{center}

Por \'ultimo, se puede lograr tambi\'en cambiar la altura del QuadRotor variando la potencia de los cuatro motores en igual medida. De esta forma se puede hacer ascender o descender la plataforma.


\begin{center}

\centering
\begin{minipage}[c]{.45\linewidth}
\centering
\includegraphics[scale=0.5]{yaw} 
\end{minipage}
\begin{minipage}[c]{.45\linewidth}
\centering
\includegraphics[scale=0.5]{up} 
\end{minipage}

\end{center}


\section{Objetivos}

Pretendemos que una vez finalizado el trabajo hayamos cumplido los siguientes objetivos. Si bien no todos est\'an directamente relacionados con el contenido de la materia son indispensables para el funcionamiento del proyecto.


\begin{itemize}
\item Armar la plataforma de forma s\'olida y prolija
\item Controlar cuatro canales de ESC\footnote{Electronic Speed Controller} independientes
\item Desarrollar protocolo para debugging y configuraci\'on en tiempo real
\item Implementar controlador PID
\item Obtener datos del sensor IntertiaCube
\end{itemize}

\section{Limitaciones}

Dada la escala y complejidad del proyecto decidimos implementar en primera instancia una versi\'on limitada del QuadRotor. Esto se ve reflejado principalmente en dos aspectos.

Primero, no-autonom\'ia energ\'etica: Los cuatro motores en r\'egimen de funcionamiento requieren una cantidad de corriente considerable. Para mantener la plataforma despegada del piso hace falta una corriente de unos 25A @ 12V. Esto equivale a una potencia de 300W.

De querer autonom\'ia en este sentido la \'unica opci\'on disponible en el mercado hoy son bater\'ias Li-Po.

Considerando el costo de las bater\'ias y la cantidad de problemas extra que pod\'ia traer esto decidimos abastecer energ\'eticamente al QuadRotor con una fuente de switching (fuente de PC standard) y dejar el problema de alimentaci\'on para un an\'alisis futuro.

La segunda limitaci\'on importante del proyecto es la no-autonom\'ia de sensado: El InertiaCube est\'a pensado para usarse conectado a una PC y no a un dispositivo $\mu$Controlado. A pesar de que el sensor se comunique via RS-232 nos fue imposible leerlo desde el $\mu$Controlador\footnote{El sensor manda los datos en un protocolo propietario, ofuscado a 115200bps.}. Es por eso que decidimos leer el sensor desde una PC con la biblioteca que provee el fabricante y mandar los datos al $\mu$Controlador. Esto nos permiti\'o implementar una interfaz de debugging en la PC que facilit\'o mucho las pruebas.

Por \'ultimo, y dado que el proyecto se encuentra en una etapa de prototipo, decidimos que vamos a realizar todas las pruebas del controlador en una sola dimensi\'on para poder resolver el problema de la forma m\'as simple. Nuestro banco de pruebas consiste en el QuadRotor suspendido por dos tanzas ligadas a uno de los dos ejes (eje de pivot) y las pruebas se realizan respecto del otro eje (eje de pruebas)

\chapter*{Dise\~no}
\addcontentsline{toc}{chapter}{Dise\~no}

\section{Generalidades}
Se presenta a continuaci\'on el diagrama en bloques de todo el sistema. La zona delimitada por la l\'inea punteada indica los componentes del proyecto que se encuentran montados en la plataforma.


\begin{center}
\includegraphics[scale=0.45]{bloques}
\end{center}


Actualmente el QuadRotor pesa 650g y tiene un di\'ametro total de 90cm. Las pruebas de potencia indican que con los motores a un 25\% la plataforma levanta vuelo.
\begin{center}

\centering
\begin{minipage}[c]{.45\linewidth}
\centering
\includegraphics[scale=0.15]{quadrotor_final} 
\end{minipage}
\begin{minipage}[c]{.45\linewidth}
\centering
\includegraphics[scale=0.15]{quadrotor_final} 
\end{minipage}

\end{center}

\newpage

\section{Hardware}

\subsection{Mec\'anica}

\subsubsection{Estructura}

La estructura del QuadRotor es de aluminio. Consiste en dos perfiles 'T' (2mm de espesor, 500mm de largo) encastrados en sus centros, formando un \'angulo de 90º. Para asegurar la rigidez de la estructura montamos sobre la uni\'on de los perfiles una plancha de aluminio de unos 10cm de lado.

\begin{center}
\includegraphics[scale=0.4]{perfiles_cruz}
\end{center}

\subsubsection{H\'elices}

Las h\'elices en general tienen 2 par\'ametros que las caracterizan: el paso y el di\'ametro. 

\begin{center}
\includegraphics[scale=0.3]{helice}
\end{center}

El paso se calcula como la distancia que recorrer\'ia la h\'elice en una vuelta si esta se moviese en un medio s\'olido (semejante a un tornillo).

Las h\'elices definen el consumo de corriente de los motores, asi como el empuje que se puede lograr. Como se vi\'o anteriormente, se necesitaba un par de h\'elices dextr\'ogiras y otro lev\'ogiras. Las \'unicas que pudimos conseguir en el mercado Argentino fueron h\'elices de 8x6 que significa: 8 pulgadas de di\'ametro por 6 de paso. Esto fue un factor limitante en el proyecto ya que el paso excesivo (6'' es demasiado para los motores que utilizamos) produjo un excesivo consumo de corriente y una respuesta muy brusca en el empuje. M\'as adelante se explicar\'a mejor, pero para una primera aproximaci\'on podr\'iamos decir que una variaci\'on en un 1\% de la velocidad de las h\'elices produce un cambio de empuje mucho mayor del que consider\'abamos necesario.

\subsubsection{Motores}

Para realizar este proyecto usamos motores brushless para aeromodelismo con control electr\'onico. A diferencia de un motor DC convencional, en un motor brushless la armadura no tiene movimiento y el im\'an permanente es el que gira sobre su eje.
Para lograr esto es necesario generar tres se\~nales con valor eficaz variable en forma cuasi-senoidal, algo parecido al siguiente gr\'afico.

\begin{center}
\includegraphics[scale=0.7]{motor_signal}
\end{center}
 
Un par\'ametro importante de un motor brushless es el $k_v$, constante que relaciona la velocidad en RPM del motor sin carga con el valor pico de tensi\'on en las bobinas del motor. Los motores del QuadRotor tienen un $k_v=1500\frac{RPM}{v}$.

\begin{center}
\includegraphics[scale=0.25]{brushless_motor}
\end{center}


\subsubsection{Paragolpes}

Para poder realizar pruebas seguras con el QuadRotor y evitar que todo el proyecto dure un solo vuelo, decidimos armar una estructura en forma de oct\'ogono que cubre toda la plataforma.
La estructura consiste en dos oct\'ogonos de fibra de vidrio alineados y separados verticalmente de tal forma que todas las partes m\'oviles del QuadRotor queden contenidas en el volumen formado.



\begin{center}
\includegraphics[scale=0.2]{PARAGOLPES}
\end{center}


\subsection{Electr\'onica}

\subsubsection{Circuito esquem\'atico}


\begin{center}
\includegraphics[scale=0.7]{../placa/schematic}
\end{center}

\newpage

\subsubsection{Controladores (ESC)}

Los controladores de los motores (ESC, Electronic Speed Controller) permiten regular la potencia suministrada a cada motor. Se alimentan con una tensi\'on que se pueda formar con celdas NiMh o LiPo. En nuestro caso son 12v. La conecci\'on al motor tiene tres cables (motor brushless).

\begin{center}
\includegraphics[scale=0.7]{esc}
\end{center}

Para controlar la potencia de los motores se usa una se\~nal de servo convencional: Es un tren de pulsos cuadrados TTL de per\'iodo $T=20ms$ y ciclo de trabajo $W$ variable entre $1ms$ y $2ms$ (0\% y 100\% respectivamente).

\begin{center}
\includegraphics[scale=0.7]{servo-signal}
\end{center}

\subsubsection{$\mu$Controlador}

Sin duda la elecci\'on del $\mu$Controlador juega un papel sumamente importante. Decidimos utilizar la marca ATMEL debido a su gran calidad de $\mu$Controladores. Algunas de las caracter\'isticas que busc\'abamos eran las siguientes:

\begin{itemize}
	\item Programaci\'on ISP
	\item 4 canales de PWM independientes
	\item USART por hardware
	\item Multiplicador por hardware
\end{itemize}

\subsubsection{Programacion ISP}
La programaci\'on del micro ISP (del ingles: ''In System Programming'') permite reprogramar el $\mu$Controlador sin la necesidad de removerlo del circuito. Esto lo vimos como una necesidad ya que en la etapa de prototipado se reprograma el $\mu$Controlador con frecuencia, y remover el $\mu$Controlador cada vez resulta tedioso y perjudicial para el hardware. 

\subsubsection{Canales de PWM}
Como se ver\'a m\'as adelante, para poder manejar los diferentes motores se necesita generar una se\~nal de PWM. El $\mu$Controlador elegido posee hasta 6 canales de PWM pero no todos con las mismas caracter\'isticas. Finalmente esto se convirti\'o en una de las principales fuentes de problemas del proyecto. 

\subsubsection{USART}
Por USART se entiende: Universal Synchronic Asynchronic Receiver Transmitter, que en castellano significa Receptor-transmisor universal tanto sincr\'onico como asincr\'onico. Este m\'odulo al ser por hardware se encarga de transmitir datos entre la PC y el $\mu$Controlador de manera paralela al funcionamiento del programa principal en el $\mu$Controlador permitiendo asi un mucho mejor desempe\~no del mismo.

\subsubsection{Multiplicador por Hardware}
Sin duda una de las cosas mas importantes del $\mu$Controlador era la posibilidad de realizar multiplicaciones por Hardware en muy pocas instrucciones de assembler. Esto era fundamental para implementar el PID ya que al t\'ermino de cada uno de los bloques (proporcional, integral y derivativo) se realiza una multiplicaci\'on por un factor que suele ser menor a la unidad. Para realizar esto se utiliza el modulo de multiplicador por Hardware. Este puede ser utilizado de varias maneras como muestran las siguientes tablas:


\begin{center}
\small{
\begin{tabular}{|l|c|}
	\hline
	\textbf{8-bit x 8-bit} & \textbf{Ciclos de clock} \\
	\hline
	Unsigned multiply 8 x 8 = 16 bits & 2 \\
	\hline
	Signed multiply 8 x 8 = 16 bits & 2 \\ 
	\hline
	Fractional signed/unsigned multiply 8 x 8 = 16 bits    & 2 \\
	\hline
	Fractional signed multiply-accumulate 8 x 8 += 16 bits & 4 \\
	\hline
	\hline
	\textbf{16-bit x 16-bit} & \textbf{Ciclos de clock} \\
	\hline
	Signed/unsigned multiply 16 x 16 = 16 bits & 9 \\
	\hline
	Unsigned multiply 16 x 16 = 32 bits & 17 \\ 
	\hline	
	Signed multiply 16 x 16 = 32 bits & 19 \\
	\hline
	Signed multiply-accumulate 16 x 16 += 32 bits & 23 \\ 
	\hline
	Fractional signed multiply 16 x 16 = 32 bits & 20 \\
	\hline
	Fractional signed multiply-accumulate 16 x 16 += 32 bits & 25 \\
	\hline
	Unsigned multiply 16 x 16 = 24 bits & 14 \\
	\hline
	Signed multiply 16 x 16 = 24 bits & 14 \\ 
	\hline
	Signed multiply-accumulate 16 x 16 += 24 bits & 16 \\
	\hline

\end{tabular}
}
\end{center}

En nuestro caso utilizamos la configuraci\'on ''Fractional signed/unsigned multiply 8 x 8 = 16 bits ''. Como se ver\'a m\'as adelante, los diferentes K (constantes de proporcionalidad) toman valores de entre 0-2 y se los debe multiplicar por n\'umeros signados de 8 bits teniendo que realizar la siguiente operaci\'on:

\begin{center}
Signado (8.0) x No-Signado (1.7) = Signado (8.8)
\end{center}

Siendo (N,Q) N la parte entera y Q la fraccionaria. Luego truncamos el valor del resultado obteniendo un numero signado (8.0)

Sintetizando, la elecci\'on del $\mu$Controlador se bas\'o en los perif\'ericos y prestaciones que necesitabamos para desarrollar el proyecto. Si bi\'en en las clases pr\'acticas se vio el 8051, consideramos que para controlar el QuadRotor nos iba a convenir usar un dispositivo de la famila MEGA de ATMEL.

\subsubsection{Sensor: InertiaCube}

InertiaCube es un sensor de orientaci\'on 3DOF (degrees of freedom) que permite conocer la rotaci\'on del mismo respecto a una terna fija.

Durante los \'ultimos a\~nos  se hicieron populares en el mercado todo tipo de sensores IMU\footnote{Inertial Measurement Unit} pero la mayor\'ia de estos no permite discriminar entre una rotaci\'on y una aceleraci\'on lineal.

InertiaCube integra la informaci\'on de 9 sensores (3 aceler\'ometros, 3 gir\'oscopos y 3 magnet\'ometros) para calcular la orientaci\'on del sensor independientemente de la aceleraci\'on lineal y de la fuerza de Coriolis que est\'en presentes.

Dado que el sensor est\'a pensado para usarse en aplicaciones de realidad virtual y no en sistemas embebidos, el protocolo de comunicaci\'on es poco amigable. La \'unica herramienta que provee el fabricante es una biblioteca de funciones para PC que permite obtener los datos del sensor.

Al comenzar el proyecto intentamos establecer la comunicaci\'on entre el sensor y el $\mu$Controlador directamente pero nos fue imposible debido al alto flujo de informaci\'on (una vez activado el sensor este comienza a mandar informaci\'on a 115200bps en forma continua) y a la falta de documentaci\'on del protocolo.


\begin{center}
%\begin{figure}
\centering
\begin{minipage}[c]{.45\linewidth}
\centering
\includegraphics[height=5cm]{screenshot_inertiacube} 
%\caption{Driver del InertiaCube}
\end{minipage}
\begin{minipage}[c]{.45\linewidth}
\centering
\includegraphics[height=5cm]{inertiacube} 
%\caption{InertiaCube}
\end{minipage}
%\end{figure}
\end{center}


\section{Software}

Para poder testear y configurar los distintos parametros del QuadRotor se desarrollo un software en C++. El software permite leer el estado del Joystick conectado a la PC asi como responder a acciones de teclado. Las caracter\'isticas que m\'as se destacan son:

\begin{itemize}
	\item Comunicaci\'on por puerto Serie (R2-232) con el QuadRotor
	\item Conexi\'on de Joystick
	\item Env\'io de constantes de proporcionalidad
	\item Env\'io de SET POINTS
	\item Recepci\'on y env\'io de datos del InertiaCube
	\item Grabaci\'on de variables del sistema enviadas por el QuadRotor
	\item Control de los diferentes aspectos del quadrotor (como la inclinaci\'on, la potencia de los motores, etc.)
	\item Visualizaci\'on en pantalla de las distintas variables del sistema
\end{itemize}

\subsection{Comandos de Teclado}

Mediante el teclado de la PC se puede realizar distintas acciones sobre el QuadRotor y el sistema en general. Las opciones disponibles (segun la tecla del teclado) son:

\begin{itemize}
	\item \textbf{A:} Comienzo de la grabaci\'on de datos
	\item \textbf{S:} Finalizaci\'on de la grabaci\'on de datos. Automaticamente graba los resultados en un archivo de valores separados por coma y una imagen PNG con el gr\'afico de los resultados.
	\item \textbf{P:} Incrementa en 1/128 el valor de Kp y lo env\'ia al microcontrolador.
	\item \textbf{O:} Decrementa en 1/128 el valor de Kp y lo env\'ia al microcontrolador.
	\item \textbf{L:} Incrementa en 1/128 el valor de Kd y lo env\'ia al microcontrolador.
	\item \textbf{K:} Decrementa en 1/128 el valor de Kd y lo env\'ia al microcontrolador.
	\item \textbf{M:} Incrementa en 1/128 el valor de Ki y lo env\'ia al microcontrolador.
	\item \textbf{N:} Decrementa en 1/128 el valor de Ki y lo env\'ia al microcontrolador.
	\item \textbf{B:} Fija un Set Point de 0 grados en el roll.
	\item \textbf{O:} Fija un Set Point de 20 grados en el roll. En conjunto con B permite enviar un escalon en el Set Point para medir la respuesta
\end{itemize}

Los resultados de la grabaci\'on de datos, la aplicaci\'on del escal\'on y las modificaciones en las constantes, se pueden observar en los gr\'aficos del ap\'endice de pruebas.

\subsection{Acciones del Joystick}

El Joystick si bien no esta del todo explotado, permitir\'a en un futuro manejar al QuadRotor. Por el momento solo permite prender y apagar el sistema asi como usar una de las palancas analogicas para controlar el Set Point del roll y en teor\'ia, el roll en si mismo del QuadRotor.
\subsection{Grabaci\'on y ploteo de resultados}

El software permite grabar los datos enviados por el QuadRotor y permite visualizar todas las variables de forma correlativa. Esto resulto de suma utilidad para el tunning del software ya que gracias a estos gr\'aficos logramos darnos cuenta de los problemas relacionados con el PWM (ver conclusiones). En el apendice de pruebas se pueden ver los resultados.
\section{Firmware}

\subsection{Generalidades}

El programa principal del firmware del $\mu$Controlador se program\'o segun el siguiente diagrama de flujo:

\begin{center}
\includegraphics[scale=0.7]{diagrama_flujo_ppal}
\end{center}

Luego se utilizan diferentes servicios de interrupci\'on (ISR):

\subsubsection{Recepci\'on de datos (USART)}

\begin{center}
\includegraphics[scale=0.7]{diagrama_flujo_usart}
\end{center}


\subsubsection{Timer0}


\begin{center}
\includegraphics[scale=0.7]{timer0}
\end{center}

\subsubsection{Timer1A}


\begin{center}
\includegraphics[scale=0.7]{timer1a}
\end{center}

\subsubsection{Timer1B}


\begin{center}
\includegraphics[scale=0.7]{timer1b}
\end{center}

(*) Si bien deshabilitar la salida de PWM cambiando el registro de direcci\'on del port parece algo poco ortodoxo e inconveniente, fue la \'unica forma que encontramos de lograr la se\~nal deseada. Hubo intentos de deshabilitar el m\'odulo PWM desde su registro de configuraci\'on pero esto generaba pulsos espurios que arruinaban la se\~nal.


\subsection{Control de Motores}

Para controlar los motores es necesario generar cuatro se\~nales de servo independientes (Ver Controladores ESC). La generaci\'on de estas se\~nales es bastante problem\'atica desde el punto de vista del $\mu$Controlador debido a su mala relaci\'on ciclo de trabajo vs. per\'iodo.

El $\mu$Controlador que usamos cuenta con seis canales PWM, dos correspondientes a cada timer.
\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline
\#	& canal	&	timer	&	resoluci\'on \\
\hline
0	& A		& 	0		& 	8bits \\
\hline
1	& B		& 	0		& 	8bits \\
\hline
2	& A		& 	1		& 	16bits \\
\hline
3	& B		& 	1		& 	16bits \\
\hline
4	& A		& 	2		& 	8bits \\
\hline
5	& B		& 	2		& 	8bits \\
\hline
\end{tabular}
\end{center}

Una primera aproximaci\'on para generar la se\~nal buscada puede obtenerse usando los m\'odulos PWM del $\mu$Controlador. Para esto habr\'ia que configurar el m\'odulo para que tenga un per\'iodo $T=20ms$ y cambiando el registro asociado a cada canal PWM (\texttt{OCRnx}) se puede variar el ciclo de trabajo desde $W=0ms$ (\texttt{OCRnx=0x00}) hasta $W=20ms$ (\texttt{OCRnx=0xFF}).

Pero teniendo en cuenta la naturaleza de la se\~nal que queremos generar, estar\'iamos usando solamente el 5\% del rango \'util del m\'odulo PWM\footnote{Considerando una resoluci\'on de 8 bits ya que buscamos sietr\'ia en el control de los motores y hay solamente dos canales de 16 bits.}.

Descartando esta opci\'on optamos por un m\'etodo un poco m\'as artesanal con el cual obtuvimos mejor resoluci\'on y se maneja con interrupciones.

Usamos el timer0 y el timer2 (los de 8 bits) en modo Fast PWM con un per\'iodo $T\approx5.4ms$ y habilitamos la interrupci\'on de overflow de estos timers. En las respectivas rutinas de interrupci\'on lo que se hace es desconectar el prescaler de cada m\'odulo. De esta forma, al producir overflow se detienen los m\'odulos y quedan en 0. Lo que se obtiene es un solo pulso de ancho variable entre $W=0ms$ y $W\approx5.4ms$. Esto sucede en $T_2\approx k\cdot20ms+5.45ms$

Por otra parte se configura el timer1 en modo comparador para que genere interrupciones en $T_0=k\cdot20ms$ y en $T_1=k\cdot20ms+2ms$ $\forall k \in N_0$. En $T_0$ se conecta el prescaler de los m\'odulos PWM (del timer0 y timer2) y en $T_1$ de deshabilita la salida de los m\'odulos PWM. Entonces cada 20ms se activan los m\'odulos y 2ms despu\'es de esto se desactivan.


\begin{center}
\includegraphics[scale=0.7]{time_diagram}
\end{center}

\subsubsection{Sintetizando}

\begin{itemize}
\item $T_0$: Habilita el prescaler y habilita la salida PWM
\item $T_1$: Deshabilita la salida PWM
\item $T_2$: Deshabilita el prescaler
\end{itemize}

\subsection{Comunicaci\'on}

La comunicaci\'on entre la PC y el QuadRotor se basa en el protocolo R2-232. Podemos dividir al sistema de comunicaci\'on en dos diferentes Capas:
\begin{itemize}
	\item Capa F\'isica
	\item Capa de Aplicaci\'on
\end{itemize}

\subsubsection{Capa F\'isica}
La comunicaci\'on se realiza mediante el protocolo serie RS-232 asincr\'onico y full duplex utilizando la siguiente configuraci\'on:

\begin{itemize}
	\item Velocidad de transmisi\'on: 57600 bps
	\item Bits de datos: 8
	\item Paridad: NO
	\item Bites de stop: 1
	\item Control de flujo: ninguno
\end{itemize}

Para ello se utiliz\'o el modulo USART por hardware que dispone el $\mu$Controlador permitiendo asi una mejora en el rendimiento del firmware ya que toda la comunicaci\'on se realiza en paralelo al programa principal y la recepci\'on de datos se realiza mediante interrupciones.

\subsubsection{Capa Aplicaci\'on}

Debido a la gran cantidad de datos que era necesario transmitir desde y hacia el $\mu$Controlador se opt\'o por implementar un protocolo a nivel de aplicaci\'on el cual permite diferenciar el tipo de paquete enviado. Este, en un principio, esta pensado solo para enviar distintos parametros al $\mu$Controlador desde la PC. Para el envio desde el $\mu$Controlador hacia la PC simplemente se mandan los datos uno tras otro en un orden preestablecido permitiendo asi un menor tiempo de transmisi\'on y un mejor manejo de recursos en el $\mu$Controlador. 

Se debe enviar desde la PC hacia el $\mu$Controlador la siguiente secuencia de datos para ser considerada valida por el $\mu$Controlador:

\begin{itemize}
	\item Cabecera de control
	\item Par\'ametro 1 (opcional)
	\item Par\'ametro 2 (opcional)\\
	\vdots
	\item Par\'ametro 15 (opcional)
\end{itemize}

La cabecera de control esta compuesta por un dato de 8 bits en el cual en nibble mas alto representa la cantidad de par\'ametros a enviar y el nibble m\'as bajo el identificador del paquete. La cantidad de parametros puede ser desde 0 (para comandos simples) hasta 15 (por ejemplo para setear las diferentes constantes del sistema P.I.D.). Esto da la posibilidad de enviar hasta 16 tipos de paquetes diferentes con hasta 15 parametros cada uno. En el siguiente gr\'afico se puede ver un ejemplo:

\begin{center}
\includegraphics[scale=0.5]{protocolo}
\end{center}

En el gr\'afico anterior se observa que el tipo de paquete es el 0x04 y eso realiza en el programa un llamado a el handler de los paquetes tipo 4. Pero antes de realizar el llamado recibe los N parametros (en este caso 3) y los guarda en la SRAM del $\mu$Controlador. Luego llama al Handler correspondiente y este lee los par\'ametros de la SRAM. Finalmente devuelve el control al programa principal.
En el firmware-software actual se utilizaron los siguientes tipos de datos:

\begin{itemize}
	\item \textbf{ANGLES (0x11): } Enviar los \'angulos medidos del QuadRotor cada vez que alguno de estos cambia. Por el momento solo envia el Roll ya que el resto de los \'angulos no fueron necesarios para las pruebas 
	\item \textbf{SET POINTS (0x12): } Envia el set point elegido en cada eje.
	\item \textbf{JOYSTICK (0x13): }Envia acciones del controlador como por ejemplo el presionar botones, o cambiar par\'ametros de vuelo
	\item \textbf{SET PWM (0x24): } Fuerza la velocidad de los motores. Se lo utiliza \'unicamente para pruebas ya que el resto del tiempo, estos son controlados por el PID
	\item \textbf{KPARAMS (0x35): }Envia las constantes de proprocionalidad para los bloques Promorcional, Integral y Derivativo
\end{itemize}

\subsection{Programa principal: PID}

El PID se realiz\'o basandonos en el siguiente diagrama de bloques:

\begin{center}
\includegraphics[scale=0.3]{PID}
\end{center}

En donde la planta representa al conjunto: ESC-Motores-Helices-InertiaCube, $u(t)$ representa el SET POINT deseado en grados, Kp, Ki y Kd las consantes de proporcionalidad del bloque proporcional, integral y derivativo e $y(t)$ representa el \'angulo medido.

\chapter*{Pruebas}
\addcontentsline{toc}{chapter}{Pruebas}

\section{Motores}

Lo primero que se hizo fue probar los motores que hab\'iamos adquirido. Dado que no conociamos nada acerca del funcionamiento de los mismos ni de sus controladores realizamos un banco de pruebas para poder medir el empuje, el consumo y otros factores en funcion de la se\~nal de entrada al controlador. El banco de pruebas utilizado fue:

\begin{center}
\includegraphics[scale=0.3]{banco_prueba_motor}
\end{center}

Como se puede ver en la imagen anterior, se coloco uno de los propulsores sobre una balanza y se midi\'o la corriente con el Amper\'imetro, la fuerza con la balanza y los resultados fueron los siguientes:


\begin{center}
\includegraphics[scale=0.7]{resultado_motores}
\end{center}

Analizando los datos pudimos obtener la siguiente conclusi\'on: tanto la corriente como el empuje se relacionan linealmente con el throttle que se le indique al controlador.


\section{PID}

Como se coment\'o en la secciones de firmware y software, el diseño nos permite guardar el estado de las variables del sistema para luego observarlas y hacer correcciones al respecto. Para poder comparar los datos obtenidos, estos se graficaron utilizando el software libre \textit{gnuplot}. Pudimos entonces medir las siguientes variables:

\begin{itemize}
	\item Constantes de proporcionalidad Kp, Ki, Kd
	\item Set Point, error del pid y angulo (roll) medido
	\item Potencia entregada a los motores
	\item La salida de cada uno de los bloques proporcional, integrativo y derivativo
\end{itemize}

A continuaci\'on se observan algunos resultados:


\begin{center}
\includegraphics[scale=0.25]{graficos/1245726258.png}
\end{center}

\section{Paragolpes}

Antes de implementar el paragolpes de fibra de vidrio hubo varias opciones para proteger las h\'elices, de las cuales llegamos a implementar una que consistia en un ducto\footnote{Considerando nuestras posibilidades, los ductos fueron creador a partir de budineras de aluminio de 25cm de di\'ametro.} de aluminio montado en cada h\'elice.
Una vez instalados los ductos volvimos a realizar las pruebas de empuje y observamos que el rendimiento del QuadRotor hab\'ia bajado significativamente.

\begin{center}
\includegraphics[scale=0.25]{budinera}
\end{center}

\chapter*{Conclusiones}
\addcontentsline{toc}{chapter}{Conclusiones}

Si bien el proyecto no est\'a finalizado podemos afirmar que los objetivos que nos propusimos est\'an cumplidos.

Para poder continuar con el proyecto necesitamos aumentar la resoluci\'on de las salidas de servo y para esto es indispensable usar una aritm\'etica de 16bits en lugar de 8bits.

Dado que no es un proyecto en el que la velocidad ni la capacidad del $\mu$Controlador est\'en en juego, tiene sentido usar un lenguaje de m\'as alto nivel para simplificar detalles que consumen tiempo de desarrollo y no aoprtan al proyecto.

Como era de esperarse, toda la construcci\'on de la estructura mec\'anica nos consumi\'o mucho tiempo de dise\~no e implementaci\'on.

Lo que tenemos hecho hasta ahora funciona de acuerdo a lo que queremos que haga, pero debido a la baja resoluci\'on de PWM no logra resolver el problema principal que es estabilizar la plataforma.

Un detalle no menor y que involucra muchos de los items mencionados anteriormente fue algo que consideramos un error en la elecci\'on del $\mu$Controlador: para elejirlo nos fijamos la cantidad de canales PWM que ten\'ia el dispositivo pero no ahondamos investigando la resoluci\'on de estos canales.

Dada la naturaleza de la se\~nal de servo, necesit\'abamos un m\'odulo PWM de altas prestaciones para generar la se\~nal de forma directa.

\chapter*{Trabajo futuro}
\addcontentsline{toc}{chapter}{Trabajo futuro}

% .. aca hay mucho para escribir (por suerte)

Teniendo en cuenta la escala del proyecto y el tiempo limitado que le dedicamos en el contexto de la materia, quedaron muchas cosas por cambiar y por mejorar.

Hemos llegado a un punto en el que estos cambios son necesarios para seguir desarrollando el QuadRotor.

En primer lugar, un cambio que sin lugar a duda urge es aumentar la resoluci\'on de PWM. Esto puede implicar cambiar el $\mu$Controlador o generar las se\~nales de servo con hardware dedicado a esto.

Una vez solucionado el tema de PWM podemos entrar en el proceso de tunning del controlador PID, es decir, encontrar los valores del controlador adecuados para que el sistema responda de forma satisfactoria.

A esta altura se podr\'a entrar en una pr\'oxima fase de prueba en la que se extienda el testing a los dos ejes del QuadRotor. Esto implica estabilizar la plataforma en roll y en pitch.

Al terminar la fase de prueba en los dos ejes, y aprovechando el software de diagn\'ostico que desarollamos es necesario medir los tiempos de respuesta y de establecimiento del sistema como controlador-planta. Esto es importante desde el punto de vista te\'orico para analizar como responde el controlador al modelo propuesto.

Relacionado con el \'ultimo punto puede ser muy interesante proponer otro modelo que no responda a la teor\'ia cl\'asica de control e implementar un controlador basado en FuzzyLogic o con algun otro enfoque. Medir y comparar los resultados con el controlador PID.

Otra linea de trabajo importante es lograr reemplazar el sensor InertiaCube por alg\'un sistema m\'as econ\'omico y que pueda ser le\'ido e interpretado desde el $\mu$Controlador. De esta forma nos estar\'iamos independizando de la PC para realizar el sensado.

Tambi\'en es necesario un v\'inculo inal\'ambrico entre la plataforma y una PC (o control remoto en general) para poder cambiar el setpoint y controlar el QuadRotor externamente, y tambi\'en para poder generar reportes con la herramienta de diagn\'ostico.

Am\'en de que la plataforma sea completamente independiente (no salgan cables de ella) es necesario un suministro de energ\'ia abordo. Tal como se mencion\'o durante el informe, la soluci\'on a esto es con celdas LiPo. A esta altura si tendr\'ia sentido invertir en las celdas ya que el prototipo estar\'ia probado y en funcionamiento.

Por \'ultimo se pueden realizar pruebas de autonom\'ia y payload. De acuerdo a estas pruebas se puede montar una c\'amara inal\'ambrica en la plataforma.









%\chapter*{Referencias}





\nocite{pidlq,wikipedia,avr201,pidphd}

\bibliography{informe-quadrotor}
\addcontentsline{toc}{chapter}{Referencias}
\bibliographystyle{ieeetr}




\appendix

\chapter{Modificaciones finales}

Una vez terminado el presente informe, y considerando que se extendi\'o el plazo de entrega del proyecto en una semana, decidimos comenzar a implementar las mejoras que propusimos en la secci\'on ''Trabajo Futuro''.

Teniendo en cuenta que cambiar de $\mu$Controlador no era una opci\'on en este momento, nos propusimos mejorar cuanto fuera posible la forma de generar la se\~nal de servos con el hardware que dispon\'iamos.

Con el m\'etodo de generaci\'on de se\~nal propuesto en el informe obtuvimos una resoluci\'on de 47 niveles \'utiles (entre $W=1ms$ y $W=2ms$). Con el m\'etodo propuesto a continuaci\'on mejoramos esto en cuatro veces. Es decir, tenemos una resoluci\'on de 188 niveles \'utiles.

Usamos el timer0 y el timer2 (los de 8 bits) en modo Fast PWM de la misma forma que antes, pero esta vez con un per\'iodo $T\approx1.3ms$ y habilitamos la interrupci\'on de overflow de estos timers. En las respectivas rutinas de interrupci\'on lo que se hace es desconectar el prescaler de cada m\'odulo. De esta forma, al producir overflow se detienen los m\'odulos y quedan en 0. Este instante lo consideramos $T_3\approx k\cdot20ms+2.3ms$

Por otra parte se configura el timer1 en modo comparador para que genere interrupciones en $T_0=k\cdot20ms$, en $T_1=k\cdot20ms+1ms$ y en $T_2=k\cdot20ms+2ms$ $\forall k \in N_0$. En $T_0$ se habilitan y se ponen en alto las salidas PWM. En $T_1$ se conecta el prescaler de los m\'odulos PWM (del timer0 y timer2) y en $T_2$ de deshabilita la salida de los m\'odulos PWM.

\begin{center}
\includegraphics[scale=0.7]{time_diagram_imp}
\end{center}

\subsubsection{Sintetizando}

\begin{itemize}
\item $T_0$: Salidas de PWM habilitadas y en estado alto.
\item $T_1$: Prescaler de timer0 y timer2 conectado.
\item $T_2$: Salidas de PWM deshabilitadas y en estado bajo.
\item $T_3$: Prescaler de timer0 y timer2 desconectado.
\end{itemize}

\chapter{C\'odigo fuente}

\begin{tiny}
\lstinputlisting{../firmware/quadrotor.asm}
\end{tiny}


\end{document}
